Modern database system architectures having dozens if not hundreds of databases that serve multiple hundreds to thousands of business transactions per second and hundreds of thousands of data selection requests. Such systems generally suffer from exhaustion of computation resources, poor response times and lack of availability. A necessary requirement of such architecture is to maintain ability to identify root cause of above-mentioned issues in a shortest time possible.
Current ways of researching these issues include:                Displaying current database performance statistics counters—used by most of the databases (for example by Oracle, DB2, MySQL, SQL Server, etc.); and        Taking a snapshot of database performance statistic counters from time points T(i) and T(i+1), and generating a report that displays differences in statistical values (used by Oracle Statspack and Oracle AWR, for example).        
The first approach helps in some cases to identify if a certain number of instrumented statistical parameter values are exceptionally high, while the second approach helps to see what are the changes in instrumented statistical parameters over the single period of time.
However, when a database system experiences performance or availability problems, displaying current database performance statistics counters and generating simple time-differential reports is often not enough to diagnose and repair the system in a timely manner. The database administrator (DBA) must generate multiple reports from the time periods when database performance was normal and manually compare hundreds of recorded parameters to identify what changed and which change has had the most impact on the database performance. The task becomes enormously difficult when multiple databases are involved. Under these circumstances, it is almost impossible for a DBA to troubleshoot performance troubles in real time, when performance problem resolution promptness is extremely critical.